In order to provide a stable IP connection for user terminals moving within and between (access) networks, the Internet Engineering Task Force (IETF) has specified a protocol known as Mobile IP. Mobile IP for IPv6 is specified in RFC 3775—“Mobility Support in IPv6”. According to Mobile IPv6, the current location of a user terminal or Mobile Node (MN) within the global network is stored in a node called Home Agent (HA). The HA dynamically updates the current location of the MN as it moves, in order to make the MN reachable for other nodes trying to connect to it. These other nodes are referred as Correspondent Nodes (CN). Mobile IP for IPv4 is specified in RFC 3344.
A MN is allocated a stable IP address, which is referred as a Home Address (HoA). When the MN is away from its home network (i.e. the network which assigned the HoA), the HA receives traffic on the behalf of the MN and then tunnels it towards the MN, i.e. communications between the MN and the CN are sent via the HA. The current location of the MN is indicated by a care-of address (CoA), and thus when the HA needs to forward a packet to the MN's current location, the HA must map the HoA to CoA. The mapping between HoA and CoA is called a “binding”.
Mobile IPv6 defines a mechanism referred to as “route optimization” which can be used to optimise the route taken by traffic between the MN and the CN, removing the HA from the route. However, route optimization is not a mandatory part of the protocol and it may not always be available for various reasons. For example, some Network Address Translation (NAT) servers may cause problems for route optimization effectively rendering its use impossible.
Recent developments in mobile communication have introduced a need to support multi-access capabilities for MNs. Consider for example a MN which is simultaneously reachable at two different CoA. One of the CoAs may be associated, for example, with a 3G access network whilst the other may be associated with a WLAN access network. The “monami6” IETF working group is currently working on the provision of multi-access support in Mobile IPv6.
MNs equipped with more than one (access) communication interface require a mechanism that controls the usage of the interfaces for communication, i.e. to direct flows to particular interfaces. Such a mechanism will apply a defined policy or policies according to selectors associated with communication flows. A typical selector set for a given flow may include the source and destination addresses for packets of the flow. In the case of Mobile IPv6, this control mechanism will be implemented within the HA that is responsible for data forwarding to a MN. When data destined to the MN's HoA arrives to the HA, the HA decides to which interface (of the MN) the data should be forwarded.
IPsec (IETF RFC 2401—“Security Architecture for the Internet protected traffic”) is an Internet protocol intended to provide encryption and authentication for IP data flows. It can be expected that IPsec will be used to secure end-to-end data flows between MNs and CNs in cases where route optimization is not employed, i.e. data flows pass through a HA. The selectors used to select a policy to apply to a data flow will typically be located within the inner IP header of an IPsec packet. As IPsec may encrypt this inner header, the selectors will not be available to the HA and therefore the home agent will not be able to select specific policy suited to the selectors and must apply some default policy. In the case of a MN having multi-access capabilities, this means that IPsec protected flows must be routed via a default communication interface which may not be optimal.
A similar situation may arise at other nodes within the transport path and which are required to apply a selector-dependent policy [see IETF RFC 4140—“Hierarchical Mobile IPv6 Mobility Management (HMIPv6)]”. Policies may not be related to selection of an appropriate communication interface, but may relate to, for example, a Quality of Service (QoS) to be applied or a decision on transmitting over multiple interfaces, e.g. bi-casting (or more generally n-casting).